In order to make efficient use of mobile network resources, the 3rd Generation Partnership Project (hereinafter referred to as 3GPP) has put forward the MBMS, a technology of sending data to multiple targets from one data source, thus sharing the network (including a core network and an access network) resources and improving the utilization ratio of network resources (especially air interface resources).
As shown in FIG. 1, multiple services can multiplex channel resources dynamically in one scheduling period. In the case shown in FIG. 1, Service S1 and Service S2 multiplex data in one scheduling period. In order to achieve synchronous transmission of the MBMS service in a cell consisting of multiple network element entities (base station network elements), the existing technology provides a processing method of synchronization protocol (SYNC), and the corresponding network system includes an upper layer network element and lower layer network elements (1˜N). As shown in FIG. 2, the synchronous transmission process of this SYNC protocol comprises the following processing steps:
Step S1. An upper layer network element sends a MBMS service data packet to each lower layer network element (1˜N), and this service data packet bears payload and carries timestamp information, data packet sequence number information, and accumulated service data length information etc. A service data packet is also called a SYNC data frame in the SYNC protocol. At the end of each synchronization sequence, the upper layer network element also sends a SYNC control frame, which carries the information indicating the total number of the data frames in the synchronization sequence corresponding to this control frame and the total length information of service data. FIG. 3 shows an example of an upper layer network element sending a synchronization sequence data frame and control frame to a lower layer network element.
Step S2. The lower layer network element receives the foregoing synchronization sequence sent from the upper layer network element, and determines by means of detecting the sequence number of the service data packets whether any service data packet is lost as well as the total length of the service data packets that are already lost.
Step S3. For the service data carried in the service data packet in the same synchronization sequence, each lower layer network element begins to send the service data packets successively at the wireless interface during the scheduling period corresponding to the timestamp of the service data packet.
Each lower network element performs the Radio Link Control (hereinafter referred to as RLC) protocol processing on the MBMS service data packet independently, which comprises distribution of RLC sequence number and RLC segmentation and concatenation. Each lower layer network element maintains the current RLC sequence number, and the initial RLC sequence number can be kept synchronous through allocation. In this way, each lower network element can keep the distribution of PLC sequence number consistent while processing data.
In the existing technology, in the case that data packets are lost (especially when it is not successive that data packets are lost), a lower layer network element can obtain the length of the lost data packet by detecting the accumulated data packet length. In such a case, the lower layer network element can set a virtual data packet whose length is the same as that of the lost data packet when performing the RLC layer protocol processing. RLC segmentation and concatenation are performed on this virtual data packet as other data packets correctly received. When being sent at a real wireless interface, sending will not be performed during a Transmission Time Interval (hereinafter referred to as TTI) in which the data of this virtual data packet is contained. Such a processing method is called mute processing. By mute processing, the mutual interference caused by the inconformity between the virtual data packet and the real service data successfully received by other network elements can be avoided. In addition, since the length of this virtual data packet is the same as that of the corresponding lost data packet, and the size of the space the virtual data packet occupies in RLC Protocol Data Unit (hereinafter referred as to PDU) is the same as that of a real data packet, the initial position of the successfully received data packet in the RLC PDU is consistent with that of the network element which has not lost any data packet. With such processing, the processing of the network element with lost data packet(s) and the network element without any lost data packets can be kept consistent.
Considering the possibility that a lower layer network element may restart, the RLC sequence number that the lower layer network element previously maintained for this MBMS service will be lost after the restarting, and then the lower layer network element will not be able to determine the RLC sequence number after performing the RLC segmentation and concatenation on the next received MBMS service data packet. In order to solve this problem, the method of resetting RLC sequence number is adopted in the existing technology. Specifically, at the beginning of a scheduling period or a predetermined time interval, the RLC sequence number starts to be distributed from an initial value (0), so that the restarted lower layer network element can keep synchronization of the RLC sequence number with other network elements again at the beginning of a scheduling period.
Considering the possibility that data packet(s) may be lost or even data packets may be lost successively when data is transmitted from an upper layer network element to a lower layer network element, according to the existing SYNC protocol technology, the lower layer network element can avoid through the mute processing the damage caused by losing data packet(s), but the forgoing method has a serious problem: in view of the particularity of the RLC processing, when the RLC processing is performed on a service data packet or called a RLC Service Data Unit (hereinafter referred to as SDU), the size of the space the service data packet occupies in RLC PDU depends on its specific location. During the RLC processing on one RLC SDU, the number of the RLC protocol Length Indications (hereinafter referred as to LI) it occupies is uncertain, capable of being 0, 1 or 2 depending on its specific situation in the RLC PDU. Therefore, during the specific processing: if the number of the lost service data packet is 1, the lower layer network element can calculate the certain space occupied in RLC PDU according to its length; if data are lost successively, the lower layer network element can just obtain the total length of those lost data packets instead of the length of each data packet among the multiple lost data packets, because the size of the real loading space of the RLC PDU that those lost data packets occupy can not be calculated correctly.
In the foregoing situation that multiple data packets are lost successively, since the lower layer network element can not obtain the length of each lost data packet, thus resulting in that the RLC processing on the service data can not be inconsistent with that of other lower layer network elements without any lost data packets, the lower layer network element can not send the service data with lost data packets. In addition, if multiple services multiplex the same channel, this lower layer network element can not send the data of other services after their data packets are lost successively, otherwise interference between cells will arose. For example, as shown in FIG. 4, the data of Service 1 is lost, which poses a problem in which Service 1 can only receive the correctly sent data after the data is lost, and the data packet(s) following the lost one and even the data packets of Service 2 can not be received.
With regard to the problem in related technologies that a lower layer network element can not keep synchronization with other lower layer network elements which receive data packets successfully in the situation that multiple data packets are lost successively, no effective solutions have been proposed till now.